When it comes to test coverage, I make zero exceptions. 100% test coverage, preferably unit test coverage, and zero warnings is what I aim for. So many times, my personal zero tolerance attitude has been challenged by colleagues and supervisors.

The simple reason is – who is the one to decide, what is to be tested, and what is not? Who is the one to decide, what is a warning, and what is not?

When I started focusing on code quality, warnings, and test coverage, I had exactly these questions, and I often was very unsure of what to test, what to fix, and what not to. After realize I had spent too much time in these decisions, I decided to just trust the developers of static code analysis. After all, many very talented developers have spent years on designing these tools for us, and as I realized over time, many of the embedded rules again are rules given by famous authors on code quality.

So, I started to just fix just each and every rule and to just blindly follow the tools. Many have called me a fool for so blindly following a “stupid” tool. However, as soon as you stop to argue and whine and just do the damn job of fixing your warnings, you will realize the overall code quality increases, as well as your knowledge about why a certain warning is a warning – because in the majority of cases, I learned, it’s just our own ignorance to not understand why a warning is a warning.

However, of course, as always, there are exceptions, and corner cases.

The problem with these is, out of 10 different developers, there will often be 20 different opinions if or if not something is to be fixed, or not, and a paralyzing debate will start. The more the number of warnings grows, the more the team feels overwhelmed by its pure size, which will very soon lead people to simply ignore all warnings and live with all of them.

If, however, you start to accept each and every warning, and you spend the time saved on discussions on fixing each and every warning, very soon you will have reached a system with zero warnings, and then you can even install warning thresholds controlled by tools such as sonar

That will turn your build in jenkins to yellow (or even red) to motivate people to instantly fix the issues.

I worked on projects of different levels of code quality. In one, we had about 200.000 lines of code and more than 10.000 warnings in the code. I talked to my colleagues and asked them to join forces and to start to fix all these warnings – what I heard was only excuses – you could never fix this amount of warnings. Well, I think, this is simple math –

10.000 dived by let’s say 10 developers, is 1000 warnings each. With 10 warnings fixed each day (and I fixed hundreds a day easily), this team will have fixed all warnings within just 100 days or 5 business month.

Sadly, my arguments didn’t get through, so I fixed all of them myself, and within just a few months, I had done it. We had reached zero warnings. With quality, I feel it’s like with body weight. Once you are fat, it’s incredibly hard to lose weight. With a high percentage rate of fat, and a low muscular mass, your body does hardly burn any fat and so gets easily fatter every day – it’s a vicious circle. If you’r slim and healthy, however, it won’t cost you much effort to keep your shape in form. With code quality, it’s just the same.

Now with test coverage, I learned, it’s no different. Yes, there are areas like private constructors or enum values, that might not make much sense of testing, from a testing perspective, and I do agree.

However, excluding tests for things “too simple to break”, you might, at best, reach a test coverage of, let’s say 82 percent. Now when you write new code that needs testing, your code coverage tool might report you

A test coverage of 78 percent, which still sounds very good, and the important lines of code to test, will be hidden in thousands of untested (and not really worth testing) lines of code.

However, things like enum values or private constructors can be VERY easily “tested”, and yes, I mean not necessarily properly tested, but to simply write a few lines to convince your test coverage tool that this code has also been tested. Doing this, reaching 100% coverage, you will easily JUMP on every untested line, and you WILL be able to see the forest for the trees.

Please, no lame excuses. Test your code, fix your warnings. Every change DOES make a difference. Start now! 🙂

[mc4wp_form]